Modern communication networks transmit information in the form of data packets or frames that are encapsulated using a plurality of different network protocols that are typically referred to as a protocol stack, with each protocol typically adding to the packet its own header. As protocol stacks associated with different packets may differ from packet to packet, for example in dependence upon type of the service provided by the packets, location of their source in the network, and equipment used to generate the packets, packet headers and their order may also differ between packets. A typical data packet may include one or more headers associated with one or more protocols of the data link Layer, or Layer 2 of the OSI model, followed by one or more headers associated with one or more protocols of the Network Layer, or Layer 3 of the OSI model, and one or more headers associated with one or more protocols of the Transport Layer, or Layer 32 of the OSI model. By way of example, an Ethernet packet may include an Ethernet, or MAC header, followed by an IP header, followed by TCP or UDP header. However, a plurality of other network protocols, including proprietary protocols of various network equipment vendors, can also be included in the protocol stack of a particular packet, adding their own headers.
Various network equipment may be required to extract information containing in one or more headers of the packet, for example for routing or network monitoring purposes. Accordingly, such equipment includes a packet header parser (PHP) that is tasked with identifying each of the packet headers, and optionally specific fields therein, to enable further packet processing, filtering and/or routing. Software running on a general purpose processor may be able to locate and extract the needed header information, provided that the physical line rates are sufficiently low, such as DS3 and below. Packets transmitted over physical links with higher rates such as OC-48 and above, however, require special purpose hardware such as network processors or ASICs to accomplish the aforementioned format-specific processing operations.
Accordingly, when large line rates such as 1 GB/s and beyond are to be accommodated, Ethernet packet header parsing logic is typically implemented in an ASIC with a hard coded real time state machine to parse any potential Ethernet packet headers, such as MAC/IP/UDP headers, from a pre-determined list of protocols to make the entire logic size to be reasonably small. The output of the packet header parser may be a pre-assigned header type number and a relative word offset for each header. One drawback of this approach is that a hard coded header parsing state machine is not able to support networks protocols that are not pre-coded therein, such as any future protocol that is yet unknown at the time of the parser design but which may appear after the ASIC/product is released. Although software-based packet header parsers can potentially be re-programmed, they are considerably slower and/or more complex, less compact and consume more power than ASIC-based hard-coded parsers, and therefore cannot be used in small network modules such as SFP transceivers and SFProbes™. Another drawback of prior art packet header parsers is that, when such parsers are used in field-deployed network equipment, even if implemented using a programmable logic, their re-programming requires deploying a skilled technician in the field.
Accordingly, an object of this invention is to provide a reconfigurable PHP that adds a degree of flexibility and reconfigurability to a hard coded PHP state machine to be able to accommodate new types of protocol headers. Another object of this invention is to provide a fast and efficient PHP that can be re-configured remotely.